There are two types of activity that are consolidated in this report. A user is 'active' if either of these holds true for the user during the time period in question.

The first is on token/JWT refreshes. There are two ways to trigger an activity event.

The first is a POST to /oauth2/token to retrieve a token (either with an auth code, a refresh token, or any other way to get a token). The second is a POST to /api/jwt/refresh, which presents a refresh token for a new access token using the FusionAuth non standard API.

The second is on "login" events:

Login events are triggered in a number of ways:

an IdP login request (performed via a POST to /api/identity-provider/login user creation user registration to an application through a login performed via a POST to /api/login or a PUT to /api/login and finally through other forms of login that don't quite fall in those flows above. These include: passwordless, one time password and 2FA.

Basically, if a user logs in or has a token generated for them, they are considered active during the timeframe.

To get User Ids, you’d want to use the Search API, and make requests in smaller windows to keep under 10k and than add the results. For example, you could request all users with a username starting with a, and then b, and so on. Definitely recommend scripting this.

As long as you have enough RAM for ElasticSearch, 10k for numberOfResults should be just fine. You’ll just need to make sure your query is narrow enough such that the totalNumberOfResults that comes back from FusionAuth is below 10k, otherwise you won’t know for sure if you received an exhaustive result set from your query.

We will be enhancing the Search API shortly to work around this Elasticsearch limitation (github issue).